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I. REAL PARTIES IN INTEREST 

The real party in interest is Noteworthy Medical Systems, Inc., as evidenced by an 
assignment recorded at Reel/Frame 014942/0484. 

II. RELATED APPEALS AND INTERFERENCES 

There is no related appeal or interference to this application. 

III. STATUS OF CLAIMS 

Claims 1-21, 23-24, 28-34, 36, 44-45, 49 and 52 are cancelled. Claims 22, 25-27, 35, 37- 
43, 46-48, 50-51 and 53-54 are pending. Claims 22, 25-27, 35, 37-40, 43, 46-48, 50-51 and 53- 
54 stand rejected under 35 USC 103 over Lavin (U.S. Patent No. 5,772,585) in view of Campbell 
(U.S. Patent No. 6,047,259) and further in view of Simborg (U.S. Patent No. 5,950,168). Claims 
41 and 42 stand rejected under 35 USC 103 over Lavin (U.S. Patent No. 5,772,585) in view of 
Campbell (U.S. Patent No. 6,047,259) and further in view of Simborg (U.S. Patent No. 
5,950,168) and further in view of Ramsay (U.S. Patent No. 5,915,971). The rejections of claims 
22, 25, 27 and 35 are hereby appealed. The rejections of claims 26, 37-43, 46-48, 50-51 and 53- 
54 stand or fall with the rejection of claims 22 and 35, from which these claims depend. 

IV. STATUS OF AMENDMENTS 

No amendment was filed after the final rejection. 
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V. SUMMARY OF CLAIMED SUBJECT MATTER 

A. Independent Claim 22 

Independent claim 22 recites a computer implemented medical record system. The 
system includes a display 10, 40 (p. 10, line 8; p.l 1, line 4) and a processor. A memory (p.5, line 
15) for storing computer readable instructions that cause the processor to render a graphical user 
interface (p.5, lines 1-1 1) on the display for inputting data into the medical record system. 

The graphical user interface including first, second and third data entry screens for 
documenting a patient encounter and for inputting data into a patient chart stored in the medical 
record system. Three data entry screens are organized into a subjective, objective, assessment, 
and plan (SOAP) format, (p.9, lines 12-20) The graphical user interface further consists of a 
reason for visit data entry field 84 (p.12, line 11) for receiving a selection of a patient's primary 
reason for visiting a medical service provider operating the medical record system. 

The first screen 50, 52 (p.l 1, line 18 to p.13, line 13; Figs. 4-7) is operative to accept data 
input relating to summary data. The summary data includes patient vital signs, patient 
complaint, patient allergies, patient medications, and patient problem data. 

The second screen 53, 110 (p. 14, line 18 to p.20, line 28; Figs. 8-17) is operative to 
accept data input relating to patient history and physical examination data. The selection 
received in the reason for visit data entry field causes the processor to automatically select a visit 
outline from a plurality of visit outlines stored in the memory, (p. 14, lines 25-28; p.15, lines 1- 
13) The automatically selected visit outline is related to the reason for the patient's visit and to 
present the visit outline in the second screen. The visit outline guides the examination by the 
medical service provider and listing the types of information that should be collected and 
recorded into the medical record system, (p. 15, lines 1-13) The presented visit outline includes 
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an item column 1 12 listing information that should be collected by the medical service provider 
in relation to the selected primary reason for the patient's visit and a value column 114 (p. 15, 
line 13) that lists the type or format of the collected information. The system dynamically 
modifies (p. 17, lines 16-26) the presentation of the information set forth in the item column of 
the visit outline in response to a user making a selection from a pre-defined set of choices 
presented in the value column of the visit outline. 

The third screen 54, 180 (p.21, lines 1-21; Fig. 18) accepts data input relating to order 
entry data. The order entry data is determined by a user of the system by referencing the 
summary data and the history and physical examination data. 

B. Independent Claim 35 

Independent claim 35 recites a method of managing patient medical treatment data. One 
step of the method is displaying a graphical user interface including first, second and third data 
entry screens 10, 40 (p. 10, line 8; p.ll, line 4) for documenting a patient encounter and for 
inputting data into a patient chart stored in a medical record system. The three data entry screens 
are organized into a subjective, objective, assessment, and plan (SOAP) format (p.9, lines 12- 
20). 

Another step is accepting data in the first screen 50, 52 (p.ll, line 18 to p. 13, line 13; 
Figs. 4-7) relating to summary data. The summary data include patient vital signs, patient 
complaint, patient allergies, patient medications, and patient problem data. 

Another step includes accepting data in the second screen (p. 14, line 18 to p.20, line 28; 
Figs. 8-17) relating to patient history and physical examination data. The second screen is 
configured by a stored visit outline that is automatically selected from a plurality of stored visit 
outlines (p. 14, lines 25-28; p. 15, lines 1-13) by the medical record system in response to the user 
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selection of a particular reason for the patient's visit to a medical service provider operating the 
medical record system. The visit outline guides the examination by the medical service provider 
and lists the types of information that should be collected and recorded into the medical record 
system, (p. 15, lines 1-13) The presented visit outline includes an item column 112 that lists 
information that should be collected by the medical service provider in relation to the selected 
primary reason for the patient's visit and a value column 1 14 (p. 15, line 13) that lists the type or 
format of the collected information. The system dynamically modifies (p. 17, lines 16-26) the 
presentation of the information set forth in the item column of the visit outline in response to a 
user making a selection from a pre-defined set of choices presented in the value column of the 
visit outline. 

Another step includes accepting data in the third screen 54, 180 (p.21, lines 1-21; Fig. 18) 
relating to order entry data. The order entry data is determined by a user of the system by 
referencing the summary data and the history and physical examination data. 

VI. GROUNDS OF REJECTION TO BE REVIEWED ON APPEAL 

A. Whether claims 22 and 35 are unpatentable under 35 U.S.C. § 103(a) as being 
obvious over Lavin (U.S. Patent No. 5,772,585) in view of Campbell (U.S. Patent No. 
6,047,259) and further in view of Simborg (U.S. Patent No. 5,950,168). 

B. Whether claim 25 is unpatentable under 35 U.S.C. § 103(a) as being obvious over 
Lavin (U.S. Patent No. 5,772,585) in view of Campbell (U.S. Patent No. 6,047,259) and further 
in view of Simborg (U.S. Patent No. 5,950,168). 
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C. Whether claim 27 is unpatentable under 35 U.S.C. § 103(a) as being obvious over 
Lavin (U.S. Patent No. 5,772,585) in view of Campbell (U.S. Patent No. 6,047,259) and further 
in view of Simborg (U.S. Patent No. 5,950,168). 

VIL ARGUMENT 

A. Independent Claims 22 and 35 Are Not Prima Facie Obvious 
Over the Cited References to Lavin, Campbell and Simborg 

1 . The Cited References File to Disclose or Suggest 
Automatically Selecting a Visit Outline 

Independent claim 22 requires that the graphical user interface presented by the medical 
record system includes "a reason for visit data entry field for receiving a selection of a patient's 
primary reason for a visit," and further requires that the system processor "automatically selects 
a visit outline from a plurality of visit outlines stored in the memory, the automatically selected 
visit outline being related to the reason for the patient's visit" These required claim limitations 
are not present in any of the cited references to Lavin, Campbell or Simborg. 

An example of the claimed "reason for visit data entry field" is shown in Figure 7 of the 
present application, as item 84. (See, below) 
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The "reason for visit data entry field" (item 84) shown in Figure 7 (above) is a drop down box 
that allows the medical service provider to select a primary reason for the patient's visit. The 
selections presented by this data entry field are linked, by the system processor, to a plurality of 
stored visit outlines that assist the medical service provider by guiding the examination and by 
listing the specific types of information that should be collected and recorded into the medical 
record system in relation to the reason for the patient's visit. In the example of Figure 7, the 
selection of "chest pain" from the data entry field causes the system processor to automatically 
select and display the stored visit outline related to this problem - chest pain. For example, as 
shown in Figure 8 of this application, below, the selection of "chest pain" as the primary reason 
for the visit has automatically triggered the "chest pain" visit outline in the patient history and 
physical examination screen. 
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If the medical service provider had selected a different reason for the patient's visit in the reason 
for visit data entry field (84), such as "Ear Pain," then the system would have automatically 
selected a different stored visit outline to guide the examination from among the plurality of visit 
outlines stored in the system memory. In this manner, the primary reason for the patient's visit is 
able to trigger the automatic selection of an appropriate visit outline that is then utilized by the 
medical service provider to efficiently and effectively guide the patient encounter. 

The Final Office Action admits that Lavin does not disclose these claim limitations. (See, 
Final Office Action at page 5, "Lavin fails to expressly teach the selection received in the reason 
for visit data entry field automatically selects a visit outline related to the reason for the patient's 
visit. . .") Furthermore, no attempt is made in the Final Office Action to show where these claim 
limitations are present in Simborg. Thus, in order for the obviousness rejection to stand, the 
required claim limitations must be present in Campbell. They are not. 
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Although the Final Office Action refers to the following portions of Campbell in support 
of the allegation that these claim limitations are disclosed: (i) abstract of Campbell; (ii) col 1, 
line 64 to col. 2, line 8; (iii) col. 2, lines 14-21; and (iv) col. 13, lines 10-18, the fact remains that 
Campbell does not disclose a system which automatically selects a visit outline from a plurality 
of stored visit outlines in relation to the selected primary reason for the patient's visit, as required 
by independent claim 22. Each of the relied-upon portions of Campbell will now be addressed in 
detail in order to prove that this reference does not disclose the claim limitations at issue. 

Turning first to Campbell's Abstract, set forth below, this portion of the reference refers 
to "physical exam software," and a "list of possible diagnosis," and "selecting a treatment 
protocol," but it does not disclose or suggest a system having a plurality of visit outlines nor does 
it disclose or suggest that the visit outlines are automatically selected based upon user input to a 
reason for visit data entry field. 

[57] ABSTRACT 

A .software system for managing a health care practice 
includes interactive software tools for conducting a physical 
exuni, suggesting tentative diagnosis, and managing a treat- 
ment protocol The physical exam software guides the user 
through a physical exam, prompting she user for input and 
dynamically genera tiog con text sensitive questions based on 
prior input, Toe diagnosis software generates a list of 
possible diagnoses based on the observations recorded from 
the physical exam. The user can interactively select a 
diagnosis by selecting a diagnosis from a rule out lis! and 
watching the display as ihe system dynamic updates, the 
status of unresolved symptoms, The user cm also select a 
treatment protocol, which is integrated with, future physical 
exams. Hie treatment protocol is integrated such that future 
exam sessions reflect the status of the treatment protocol and 
remind the user which services need to be performed and 
wkm they should be performed. 



In fact, the Abstract of Campbell (immediately above) tends to indicate that there is only one 
programmed type of physical exam as distinguished from the "plurality of visit outlines that are 
programmed into the claimed system and which are automatically selected based upon the 
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primary reason for the patient's visit. Although Campbell's approach may be appropriate for a 
general physical examination in which there is no particular reason for the patient's visit, it is 
inefficient and time-consuming when the patient has come to the medical service provider with a 
specific problem, such as chest pain. Thus, the Abstract of Campbell does not disclose the 
required claim language. 

Column 1, line 64 through column 2, line 8 of Campbell, set forth below, discusses an 
"interactive user interface screen for conducting an interactive medical exam," and also 
discusses a "treatment protocol" that can be selected by a doctor "such that future interactive 
exam sessions display reminders to perform services in the protocol." 

When installed in a medical office or hospital, the system 
software of the invention can be executed in a network 
configuration or in a stand-alone computer. The system 
software displays interactive user interface screens for con- 65 
ducting art interactive medical exam, generating diagnoses 
of abnormal observations, and managing a treatment proto- 

2 

col The treatment protocol can be integrated with the 
interactive medical exam component of the system. For 
example, the doctor can select a treatment protocol from a 
user interface displaying computer generated diagnoses. In 
5 response, the system schedules the treatment protocol such 
that future interactive exam sessions display reminders to 
perform services in the protocol, and prompt the user to 
make observations related to the selected diagnoses. Once 

(Campbell, col. 1, line 64 to col. 2, line 8) 
There is nothing in this portion of Campbell, however, which discloses or suggests a plurality of 
visit outlines that are automatically selected by the system in relation to the reason for a patient's 
visit. It is clearly missing any notion of this teaching from claim 22. 
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Column 2, lines 14-21 of Campbell, set forth below, discuss the examination screens 
displayed in his general physical examination, stating that these screens "guide the user through 
a complete medical exam," and also that these screens display "predetermined observations and 
enable the user to select among the observations to record abnormal findings." 

Tlie interactive medical exam component of the system 
15 displays physical exam screens that guide the user through 
a complete medical exam. The screens display predeter- 
mined observations and enable the user to select among the 
observations to record abnormal findings. The system 
dynamically updates the patient's record and evaluates the 
20 input to generate additional context sensitive prompts to 
record additional observations. 

(Campbell col 2, lines 14-21) 
Here, Campbell is actually teaching away from the presently-claimed invention by stating that 
his screens "guide the user through a complete medical exam ," (emphasis supplied) which as 
noted above would be very inefficient and time consuming where the patient has come to see the 
doctor for a particular problem, such as chest pain. There is simply nothing in this portion of 
Campbell that would disclose or suggest a plurality of stored visit outlines that are automatically 
selected by the system in relation to the reason for the patient's visit. To the contrary, in fact, 
this portion of Campbell teaches a single, general set of "predetermined observations" that relate 
to "a complete medical exam." This is the antithesis of the invention set forth in independent 
claim 22. 

And finally column 13, lines 10-18 of Campbell, set forth below, describe a series of 
"buttons" that a user can operate to manually select to display a portion of the general physical 
examination. 
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When the user clicks on any of these buttons, the system 10 
launches a new screen for the selected part of the physical 
exam, Hie interactive exam screens guide the user through 
the physical exam- As user eaters information (by clicking 
on buttons or entering text), the server dynamically updates 
the database and evaluates the data to determine whether to 15 
prompt the user for additional information by displaying 
questions and supplemental screens that prompt the user to 
input medical observations, 

(Campbell, col 13, lines 10-18) 
Figure 4 of Campbell shows this manual selection of the various portions of the physical exam. 
When a user "selects" a button (420 in Figure 4), the system then brings up a predetermined 
physical exam screen (Figure 5) in response to the user-selected portion of the overall physical 
exam. This single, predetermined physical examination screen is broken down into a number of 
areas, such as "Overall Condition " "Coat and Skin," "Ocular," etc. The user of Campbell's 
system has to manually select one or more of these areas in order to be presented with a 
completely separate examination "screen" (Figure 5) that is used to collect information regarding 
the selected portion of the examination: "The physical exam buttons represent the top level in a 
hierarchy of physical exam screens. The physical exam is broken into the following areas: 1) 
Overall Condition. . . 12) Behavioral When the user clicks on any of these buttons, the system 
launches a new screen. . . " (Campbell at col. 12, line 59 to col. 13, line 1 1) 

Missing from this portion of Campbell, however, is any disclosure or suggestion of 
automatically selecting a specific visit outline that has been customized to guide the examination 
by the medical service provider in relation to the reason for visit input to the system. In 
Campbell, the examination screens are generic and unrelated to the reasons for the patient's visit, 
whereas in the system disclosed and claimed in claim 22, the visit outlines are specific to the 
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reason for the patient's visit and are designed to efficiently and effectively gather only the 
pertinent information relevant to that reason. 

In summary, the Campbell reference fails to disclose or suggest a plurality of visit 
outlines, but rather teaches a single physical examination broken down into a number of areas. 
Moreover, Campbell fails to disclose or suggest automatically selecting one of the plurality of 
stored visit outlines in response to a selection of the primary reason for the patient's visit, but 
rather teaches that the user must manually select a sub-set of the single physical examination 
process. Because these claim limitations are clearly missing from Campbell, and admittedly 
missing from Lavin and Simborg, the obviousness rejection of claim 22 is in error and must be 
withdrawn. 

2. The Cited References Fail to Disclose or Suggest 
Dynamically Modifying a Visit Outline 

Independent claim 22 also recites the function of "dynamically modifying the 
presentation of the information set forth in the item column of the visit outline in response to a 
user making a selection from a pre-defined set of choices presented in the value column of the 
visit outline" The visit outline described in claim 22 includes "an item column listing 
information that should be collected by the medical service provided in relation to the selected 
primary reason for the patient's visit and a value column that lists the type or format of the 
collected information." 

In the presently-claimed invention, a "visit outline" is a data entry item that both guides 
the examination by listing the information that should be collected, and serves as a template for 
how the information should be recorded. (See, specification at 15) Moreover, as set forth in 
claim 22, the claimed visit outline is also dynamic in that the information to be collected in the 
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"item column listing" changes depending upon user selections presented in the 'value column" 
This teaching is clearly missing from the cited references. 

The Final Office Action makes no attempt to show where such a "dynamically 
modifiable" visit outline is disclosed in either Lavin or Campbell, and thus the claim language 
must be met by the disclosure of Simborg in order for the obviousness rejection to stand. The 
Final Office Action refers to the following portions of Simborg in support of the allegation that 
this teaching is present: (i) col. 2, line 63 to col. 3, line 13; (ii) col. 4, lines 18-29 and 54-63; and 
(iii) col. 5, lines 44-61 and Figure 4. Although Simborg appears to show something similar to an 
"item column" and a "value column," it does not disclose a "visit outline" as claimed, nor is 
there any evidence of record that would support the conclusion that Simborg' s display is 
"dynamically modifiable. . . in response to a user making a selection from a pre-defined set of 
choices presented in the value column of the visit outline" as required by claim 22. Each of the 
relied-upon portions of Simborg will now be addressed in detail in order to prove that this 
reference does not disclose the claim limitations at issue. 

Turning first to col. 2, line 63 to col. 3, line 13 of Simborg, set forth below, this portion 
of the reference discloses a hierarchical "outline" having a category column and an item column. 

FIG. 1 is a first example of a display 10 which is part of 
a user interface according to the present invention. A user 
65 views display 10 and can interact with display 10 by 
positioning a cursor 12 over a display element or by using 
a keyboard, as is well known in the art. Display 10 is divided 
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into several sections, such as a category column 14, an item 
column 16 and one or more observation columns 18. Each 
category in category column 14 has a category label 20 
identifying the category and each data item in item column 
16 has an item label 22 identifying the data item. The data 
items are organized under each category into a hierarchical, 
or outline, structure with some data items being parent items 
and some data items being child items. For example, in FIG. 
1, "Asthma" is one of the data items in the category 
"Problem". "Asthma" is the parent term to the children data 
items "Lungs" and "Heart". "Lungs" in turn, is the parent to 
its children "Wheezes" and "DOE". Each observation col- 
umn 18 has a value box associated with each data item 
although some might be blank or unused. 



(Simborg, col 2, line 63 to col 3, line 13) 



Although this portion of Simborg teaches a display having a category column and an item 
column, there is nothing in this portion of the reference that refers to this display screen as being 
dynamically modifiable. In addition, there is nothing in this portion of the reference that would 
disclose or suggest that data input to the item column causes any modification of the information 
displayed in the category column. Thus, this portion of Simborg fails to disclose or suggest the 
claimed subject matter. 

Column 4, lines 18-29 and 54-63, set forth below, discloses a process whereby a user can 
manually add items to the outline by clicking certain buttons. 
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Within each observation column 18 are the observation 
values, such as observation value 30 in FIG. 1, correspond- 
ing to the data item label for that row For example, FIG. 1 
15 shows that during an encounter on Apr. 22, 1996, the patient 
had a blood pressure of 130/85. Not all data items need have 
values for each encounter. 

Data items can be added to the existing data items by 
selection using item buttons 32 shown in FIG. 1. Clicking on 

20 an item button 32 provides the user with a list of items for 
the selected category which can be added. The "Problem" 
category contains data items relating to diagnoses, 
symptoms, signs, and the like. The "Procedure" category 
contains data items relating to laboratory tests, X-rays and 

25 other procedures. The "Therapy" category contains data 
items relating to medications, diets and the like. For longer 
notes such as discharge summaries, history and physicals, 
operative reports and the like, the "Text Note" category is 
used. 

A "KnowMed" is a term used to describe a medical 
55 knowbot. A "knowbot" is a "knowledge robot" or software 
agent which can be "trained" or configured to filter large 
amounts of available data and present only data considered 
relevant to an individual user. Thus, a KnowMed is a 
software agent acting on behalf of a user to determine which 
60 data from among the large EMR database of a patient should 
be displayed and in what format. Of course, depending on its 
training, the KnowMed might also be acting on behalf of the 
organization to which the user belongs as well. 

(Simborg, col. 4, 11. 18-29 and 54-63) 
Here again, like the first portion of Simborg relied upon above, there is nothing about the 
"outline" being dynamically modifiable in response to a user making a selection from a pre- 
defined set of choices presented in the value column of the visit outline. Rather, in this portion 
of Simborg, the outline is modified by a user manually adding categories to the outline. Column 
4, lines 54-63 refers to something called a "KnowMed," nothing more. 
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And finally, column 5, lines 44-61 of Simborg, set forth below, discloses further 
information about a particular "KnowMed" that presents additional categories that may be added 
to the outline based on prior patient encounters. 

FIG. 4 shows an example of a New Problem KnowMed 
for the Angina Pectoris. The data items in the Verify cat- 45 
egory are those which the user has most often added to other 
patients' records when adding a new diagnosis of Angina 
Pectoris. The question marks (?) next to each item are to 
indicate that the user must select each item that s/he wishes 
to enter into this patient's record. This is done by clicking on 50 
the item. The zipped state, hierarchical location, show/hide 
tag, etc. of these additional items are also determined by the 
New Problem KnowMed. 

The content and format of the data items displayed in the 
Verify category are determined by the New Problem 55 
KnowMed in a similar fashion to the Chartview KnowMed. 
Its logic tabulates the data items and their formats which 
were added to the record on the previous occasions when the 
user added the triggering diagnosis, symptom or sign. Again, 
the modal behavior will be used unless overridden by an 60 
empirical rule. 



(Simborg, col 5, 11 44-61) 
Here again, however, nothing in the cited portions of the Simborg reference discloses a 
dynamically modifiable visit outline that responds to a user making a selection from a pre- 
defined set of choices presented in the value column of the visit outline. 

Therefore, because these additional claim limitations are clearly missing from Simborg, 
the obviousness rejection of claim 22 is in error and must be withdrawn. 

Independent claim 35 includes similar limitations to those argued herein with respect to 
claim 22, and therefore this claim is likewise distinguishable from the cited references. 
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B. Dependent Claim 25 is Not Prima Facie Obvious 

Over the Cited References to Lavin, Campbell and Simborg 

Dependent claim 25 depends from claim 22 and adds the limitation of "a carepath 
module linked to the selected visit outline for suggesting a particular medical treatment in 
response to the data input in the first, second and third screens into the patient's chart, the 
carepath module automatically determining that additional data entry is required to evaluate 
the patient's condition in order to make a suggestion and prompting the user of the medical 
record system to input the additional data:' This additional limitation to the claims is missing 
from the cited references. 

The Final Office Action admits that the primary reference to Lavin "fails to expressly 
teach a carepath module linked to the selected visit outline for suggesting a particular medical 
treatment" and also admits that Lavin "fails to expressly teach the carepath module 
automatically determining that additional data entry is required to evaluate the patient's 
condition" as required by claim 25. Making up for this missing teaching, the Final Office 
Action turns to Campbell and Simborg, in combination. The portions of these references relied 
upon for this additional claimed subject matter, however, simply do not disclose or suggest the 
subject matter of this dependent claim. 

First, the Final Office Action erroneously refers to the Abstract, col. 1, line 64 to col. 2, 
line 8, col. 2, lines 14-21 and col. 13, lines 10-18 of Campbell as allegedly teaching the claimed 
"carepath module." These portions of Campbell, however, refer to a "treatment protocol" which 
is displayed to the medical service provider. This appears to be a simple look-up table type of 
implementation that does not provide any logic or intelligence built into the carepath. In the 
carepath module described in claim 25, for example, the suggestion of a particular medical 
treatment is made in response to the data input to the first, second and third data entry screens . 
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and, moreover, the carepath module is smart enough to determine that additional data is required 
in order to make a suggested treatment and thereafter automatically prompts the user to enter the 
needed data. In Campbell, by distinction, the "treatment protocol" must be manually selected by 
the medical service provider, it is not "linked to" a selected visit outline as required by claim 25, 
nor does it make suggestions based upon the data input to the system, nor does it automatically 
prompt the user to enter needed data suggest a treatment: "The doctor can then launch a protocol 
by clicking on the protocol button. In response, the client sends a message to the server, which 
changes the status of the diagnosis to Undergoing therapy. . . To generate a protocol the server 
looks up the protocol in a protocol table using the selected diagnosis as a key" (Campbell, col. 
17, lines 32-40) As demonstrated by this portion of Campbell, which is not referenced in the 
rejection, the "protocol" is manually selected by the doctor, and it is not linked to any visit 
outline but instead appears to be linked to a tentative diagnosis. Thus, Campbell does not 
disclose or suggest the functionality set forth in claim 25. 

Apparently recognizing this shortcoming of Campbell's disclosure, the Final Office 
Action also refers to the same portions of Simborg set forth above in detail that were used in 
respect of the rejection of claim 22. Specifically, the Final Office Action alleges that these 
portions of Simborg (col. 2, line 63 to col. 3, line 13; col. 4, lines 18-29 and 54-63; col. 5, lines 
44-61; all of which are presented above) disclose a carepath module that automatically 
determines that additional data entry is required to evaluate the patient's condition in order to 
make a suggestions and prompting the user of the medical record system to input the additional 
data. This is clearly wrong. The portions of Simborg relied upon in rejecting claim 25 do not 
even relate to a carepath, let alone one that is linked to a visit outline. Moreover, there is no 
teaching or suggestion in these portions of Simborg where the carepath module automatically 
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determines that additional data entry is required and prompting the user to input the additional 
data. Instead, as shown above, the user of the Simborg system must manually add categories to 
the outline. 

Therefore, because these additional claim limitations are clearly missing from the cited 

references the obviousness rejection of claim 25 is in error and must be withdrawn. 

C. Dependent Claim 27 is Not Prima Facie Obvious 

Over the Cited References to Lavin, Campbell and Simborg 

Dependent claim 27 depends from claim 22 and adds the limitation of "a data repository 

including genogrammatical data, wherein the system graphically maintains the patient's 

family medical history in a genogram" This additional limitation to the claims is missing from 

the cited references. 

The Final Office Action points to column 7, line 62 through column 8, line 8 of Lavin in 
finding that this additional claim limitation is met. This portion of Lavin is describing Figure 10 
of the Lavin patent, which provides a graphical user interface for entering family medical history 
into Lavin' s system. Here, a user of Lavin' s system can enter family members by name, 
relationship and also list the types of medical conditions for those family members. What is 
clearly missing from Lavin, however, is any mention of graphically maintaining the patient's 
family medical history in a genogram as recited in claim 27. 

A genogram is a graphic representation of a family tree that displays detailed data on the 
relationships among individuals in the family tree. (See, www. genopro . com/geno gram/ for this 
definition of a genogram.) Further information regarding the content and structure of a typical 
genogram can be found at www.wikipedia.org/genogram/ . Here, it is explained that a genogram 
goes beyond a traditional family tree by allowing the user to visualize hereditary patterns and 
psychological factors that punctuate relationships. Moreover, a genogram can be used to identify 
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repetitive patterns of behavior and to recognize hereditary tendencies. (See, 
www.wikipedia.org/Renogram/ ). 

There is no disclosure of a genogram in Lavin. Figure 10 of Lavin, as noted previously, 
is simply a data entry screen, it is not a genogram. Therefore Lavin does not disclose the subject 
matter of claim 27, which requires that the system graphically maintains the patient's family 
medical history in a genogram. Because these additional claim limitations are clearly missing 
from the cited references the obviousness rejection of claim 27 is in error and must be 
withdrawn. 

VIIL CLAIMS APPENDIX 

A Claims Appendix setting forth the claims involved in this appeal are attached. 

IX. EVIDENCE APPENDIX 

No evidence is being submitted pursuant to 37 C.F.R. §§ 1.130, 1.131, or 1.132, nor is 
there any other evidence entered by the Examiner or relied upon by the Applicant. An Evidence 
Appendix indicating "None" is attached. 

X. RELATED PROCEEDINGS APPENDIX 

There are no proceedings relating to this application. A Related Proceedings Appendix 
indicating "None" is attached. 
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CLAIMS APPENDIX 



1-21. (Cancelled) 

22. (Previously Presented) A computer implemented medical record system, comprising: 
a display; 
a processor; and 

a memory for storing computer readable instructions that cause the processor to render a 
graphical user interface on the display for inputting data into the medical record system; 

the graphical user interface including first, second and third data entry screens for 
documenting a patient encounter and for inputting data into a patient chart stored in the medical 
record system, wherein the three data entry screens are organized into a subjective, objective, 
assessment, and plan (SOAP) format, the graphical user interface further consisting of a reason 
for visit data entry field for receiving a selection of a patient's primary reason for visiting a 
medical service provider operating the medical record system; 

the first screen being operative to accept data input relating to summary data, the 
summary data including patient vital signs, patient complaint, patient allergies, patient 
medications, and patient problem data; 

the second screen being operative to accept data input relating to patient history and 
physical examination data, wherein the selection received in the reason for visit data entry field 
causes the processor to automatically select a visit outline from a plurality of visit outlines stored 
in the memory, the automatically selected visit outline being related to the reason for the 
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patient's visit and to present the visit outline in the second screen, the visit outline guiding the 
examination by the medical service provider and listing the types of information that should be 
collected and recorded into the medical record system, wherein the presented visit outline 
includes an item column listing information that should be collected by the medical service 
provider in relation to the selected primary reason for the patient's visit and a value column that 
lists the type or format of the collected information, and wherein the system dynamically 
modifies the presentation of the information set forth in the item column of the visit outline in 
response to a user making a selection from a pre-defined set of choices presented in the value 
column of the visit outline; and 

the third screen being operative to accept data input relating to order entry data, the order 
entry data being determined by a user of the system by referencing the summary data and the 
history and physical examination data. 



23-24. (Cancelled) 



25. (Previously Presented) The system of claim 22, further comprising a carepath module linked 
to the selected visit outline for suggesting a particular medical treatment in response to the data 
input in the first, second and third screens into the patient's chart, the carepath module 
automatically determining that additional data entry is required to evaluate the patient's 
condition in order to make a suggestion and prompting the user of the medical record system to 
input the additional data. 



24 



26. (Previously Presented) The system of claim 22, wherein the graphical user interface further 
includes a plurality of picklists coupled to the selected visit outline for entering data into the 
medical record system, the picklists including a plurality of data entry choices programmed into 
the system that are responsive to a particular item of information to be collected by the medical 
service provider. 

27. (Previously Presented) The system of claim 22, further comprising a data repository 
including genogramatical data, wherein the system graphically maintains the patient's family 
medical history in a genogram. 

28-34 (Cancelled) 

35. (Previously Presented) A method of managing patient medical treatment data, comprising: 

displaying a graphical user interface including first, second and third data entry screens 

for documenting a patient encounter and for inputting data into a patient chart stored in a medical 

record system, wherein the three data entry screens are organized into a subjective, objective, 

assessment, and plan (SOAP) format; 

accepting data in the first screen relating to summary data, the summary data including 

patient vital signs, patient complaint, patient allergies, patient medications, and patient problem 

data; 

accepting data in the second screen relating to patient history and physical examination 
data, wherein the second screen is configured by a stored visit outline that is automatically 
selected from a plurality of stored visit outlines by the medical record system in response to the 
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user selection of a particular reason for the patient's visit to a medical service provider operating 
the medical record system, the visit outline guiding the examination by the medical service 
provider and listing the types of information that should be collected and recorded into the 
medical record system, wherein the presented visit outline includes an item column listing 
information that should be collected by the medical service provider in relation to the selected 
primary reason for the patient's visit and a value column that lists the type or format of the 
collected information, and wherein the system dynamically modifies the presentation of the 
information set forth in the item column of the visit outline in response to a user making a 
selection from a pre-defined set of choices presented in the value column of the visit outline; and 
accepting data in the third screen relating to order entry data, the order entry data being 
determined by a user of the system by referencing the summary data and the history and physical 
examination data. 

36. (Cancelled) 

37. (Previously Presented) The system of claim 22, further comprising a medication pop-up tool 
accessible from the third screen facilitating entry of medication orders. 

38. (Previously Presented) The system of claim 37, wherein the pop-up tool presents a list of 
available medications for selection by a user. 

39. (Previously Presented) The system of claim 38, wherein the pop-up tool enables the user of 
the system to record the history of a selected medication. 
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40. (Previously Presented) The system of claim 38, wherein the pop-up tool prompts the user to 
input data for a new medication. 



41. (Previously Presented) The system of claim 38, wherein the pop-up tool presents a 
calculator tool to calculate medication dosage or receive other medication guidelines in response 
to a user input. 

42. (Previously Presented) The system of claim 41, wherein the calculator pre-populates fields 
by drawing previously entered data into outlines presented on the first and second screens. 

43. (Previously Presented) The system of claim 22, further comprising add-on notations that 
can be attached to any element of a visit outline displayed on the second screen to accommodate 
data entry regarding exceptional situations that are not specifically addressed in the visit outline. 

44-45. (Cancelled) 

46. (Previously Presented) The system of claim 37, further comprising a pop-up tool for data 
entry, the pop-up tool facilitating the annotation of a graphical image using text, drawing tools, 
or both. 

47. (Previously Presented) The system of claim 37, wherein the system enables a user to mark 
locations on a graphical image of a body system. 
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48. (Previously Presented) The system of claim 37, wherein the system enables a user to 
identify a body region by marking a location on a graphical image of a body system. 

49. (Cancelled) 

50. (Previously Presented) The system of claim 22, wherein the system is capable of 
dynamically modifying the on-screen presentation of a visit outline in response to the user of the 
system marking a location on a graphical image of a body system. 

51. (Previously Presented) The medical record system of claim 22, wherein the three data entry 
screens are selected by three tabs located on a top portion of the user interface, and a plurality of 
data viewing screens are selected by a plurality of tabs located on a side portion of the graphical 
user interface. 

52. (Cancelled) 

53. (Previously Presented) The system of claim 26, wherein the picklist choices are initially set 
to a normal condition. 

54. (Previously Presented) The system of claim 53, further comprising an all normal structure for 
selecting the normal condition for each choice presented through a picklist. 
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EVIDENCE APPENDIX 



NONE 
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RELATED PROCEEDINGS APPENDIX 



NONE 
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